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Abstract 

During  the  present  reporting  period,  the  datacomputer  system 
achieved  its  initial  operating  capability  on  the  Arpanet, 
and  a  number  of  host  sites  began  using  the  service.  For 
the  month  of  July,  the  number  of  weekly  connections  to  the 
system  averaged  about  500. 
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1.  Overview 

1.1  Review  of  Basic  Concepts 

The  goal  of  the  project  continues  to  be  the  development  of 
a  shared,  large-scale  data  storage  utility,  to  serve  the 
needs  of  the  Arpanet  community. 

The  system  under  development  will  make  It  possible  to  store 
within  the  network  such  files  as  the  ETAC  Weather  Pile  or 
the  NMRO  Seismic  Data  File,  which  are  measured  In  hundreds 
of  billions  of  bits,  and  to  make  arbitrarily  selected  parts 
of  these  files  available  within  seconds  to  sites  requesting 
the  Information.  The  system  Is  also  Intended  to  be  used  as 
a  centralized  facility  for  archiving  data,  for  sharing  data 
among  the  various  network  hosts,  and  for  providing  Inexpensive 
on-line  storage  to  sites  which  need  to  supplement  their  local 
capability. 

Logically,  the  system  can  be  viewed  as  a  closed  box  which 
Is  shared  by  multiple  external  process  >rs,  and  which  Is 
accessed  In  a  standard  notation,  "datalanguage"  (see  Fig.  1). 
The  processors  can  request  the  system  to  store  Information, 
change  Information  already  stored  In  the  system,  and  retrieve 
stored  information.  To  cause  the  datacomputer  to  take  action, 
the  external  processor  sends  a  "request"  expressed  In  data- 
language  to  the  datacomputer,  which  then  performs  the  desired 
data  operations. 

From  the  user’s  point  of  view  the  datacomputer  Is  a  remotely- 
located  utility,  accessed  by  telecommunications.  It  would  be 
Impractical  to  use  such  a  utility  if,  whenever  the  user  wanted 
to  access  or  change  any  portion  of  his  file,  the  entire  file 
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Figure  1.  Logical  View  of  Datacomputer 
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had  to  be  transmitted  to  him.  Accordingly,  data  management 
functions  (information  retrieval,  file  maintenance,  backup, 
access  security,  creation  of  direct  and  inverse  files,  main¬ 
tenance  of  file  directories,  etc.)  are  performed  by  the  data- 
computer  system  itself.  The  user  sends  a  "request",  which 
causes  the  proper  functions  to  be  executed  at  the  datacomputer 
without  requiring  entire  files  to  be  shipped  back  and  forth. 

The  hardware  of  the  system  is  shown  in  overview  in  Fig.  2 
and  in  greater  detail  in  Fig.  3. 

The  program  for  the  system  processor  handles  the  interactions 
with  the  network  hosts  and  is  designed  to  control  up  to  three 
levels  of  storage:  primary  (core),  secondary  (disk),  and 
tertiary  mass  storage.  Currently,  the  CCA  facility  is  operating 
with  primary  and  secondary  storage  only,  with  the  addition  of 
tertiary  storage  planned  for  1974.  Installation  of  a  tertiary 
storage  module  will  leave  datalanguage  unchanged,  and  will 
therefore  be  imperceptible  to  users  of  the  system  (except 
insofar  as  it  affects  performance  and  the  total  storage  capacity 
available  for  data). 

In  addition  to  using  the  dedicated  equipment  at  CCA  it  is 
planned  that  datacomputer  service  will  also  make  use  of 
hardware  resources  located  at  NASA/Ames,  using  CCA  software. 

The  two  sites  will  provide  mutual  backup  for  one  another, 
thereby  guarding  against  accidental  loss  of  data  and  providing 
for  satisfactory  uptime  of  the  overall  service. 

1.2  Status  of  Project 

During  the  present  reporting  period,  the  datacomputer  system 
achieved  its  initial  operating  capability  on  the  Arpanet,  and 
a  number  of  host  sites  began  using  the  service  (see  Section  4). 
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Figure  2.  Hardware  Overview  of  System 
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Figure  3.  Hardware  Block  Diagram  -  CCA  Installation 

(Equipment  in  dashed  outline  is  planned  for  197^0 


The  service  Is  based  on  Version  0/9,  which  was  completed 
during  the  present  period.  (Previous  versions  of  the  system 
had  been  used  only  for  demonstration  and  for  internal  CCA 
development  purposes.)  This  version  offers  a  (somewhat  primitive) 
subset  of  the  capabilities  of  the  full  datalanguage  discussed 
in  Working  Paper  No.  3* 

The  primary  restriction  of  Version  0/9  is  that  elementary  data 
types  must  be  fixed-length  ASCII  strings.  This  restriction 
will  be  lifted  in  Version  0/10,  scheduled  for  December  1973, 
which  will  provide  a  larger  subset  of  the  datalanguage  capa¬ 
bilities. 

Currently,  only  disk  storage  is  available  internally  to  the 

Q 

system.  (Total  disk  storage  is  9  x  10  bits,  to  be  Increased 
to  2.3^  x  10^  bits  In  the  fourth  quarter  of  1973.)  Plans  call 
for  the  addition  of  tertiary  storage  in  197^.  Since  data¬ 
language  is  device-independent,  these  Increases  In  storage 
capacity  will  not  affect  the  user  programs  running  on  network 
hosts. 


2.  Design  Activities 
2.1  Datalanguage 

A  formal  specification  of  datalanguage  Version  0/9  was  completed 
(see  Appendix). 


Progress  was  made  in  the  specification  of  datalanguage  for 
Version  0/10.  This  version,  to  be  available  over  the  network 
in  December  1973,  incorporates  a  data  security  facility  at 
the  directory  level,  more  general  data  types  and  more  general 
data  structures.  Specifically,  there  are  arbitrary  byte 
strings  as  well  as  character  strings.  Variable  length  as  well 
as  fixed  length  containers  are  permitted.  In  his  data  des¬ 
cription,  the  user  has  some  control  over  alignment  of  logical 
object  and  physical  object  boundaries.  Physical  byte  sizes  of 
36,  32  and  8  are  supported. 

Based  on  the  results  with  datalanguage  to  date,  a  major  design 
iteration  has  begun.  In  the  revised  language,  attention  will 
be  given  to  more  general  data  structures,  pointers,  a  syntax 
that  is  better  for  generation  of  language  requests  by  programs, 
language  extensibility,  multiple  descriptions  of  data,  data 
integrity  and  privacy. 

From  the  first  language  design  period,  the  biggest  changes  in 
thinking  have  come  from  a  better  understanding  of  the  data 
sharing  problem  on  the  network  scale.  In  order  for  the  network 
community  to  get  the  most  out  of  the  datacomputer  facility, 
groups  of  users  must  be  able  to  do  two  things  they  could  not 
do  well  with  the  Initial  language:  (1)  develop  their  own  systems 
of  shared  software  that  reside  at  the  datacomputer,  and 
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(2)  have  a  description  of  the  data  that  is  independent  of 
both  the  stored  organization  and  the  descriptions  used  by 
others. 

That  is,  users  must  be  able  to  have  shared  collections  of 
access  functions,  data  validation  functions,  and  the  like, 
specified  in  datalanguage ,  stored  at  the  datacomputer ,  and 
associated  with  particular  collections  of  data.  Only  in  this 
way  can  distributed  systems  of  user  programs  have  a  shared, 
centralized  data  management  facility  that  is  built  around  the 
datacomputer  software  but  specialized  for  their  requirements. 

The  independent  description  facility  is  needed  so  that  the 
proper  modularity  cun  be  designed  into  the  global  system 
involving  datacomputer  software,  user  requests,  user  files 
stored  on  the  datacomputer,  data  descriptions,  and  a  distributed 
system  of  user  programs.  It  will  be  important  to  make  com¬ 
ponents  of  such  large  systems  as  independent  as  possible.  User 
programs  should  be  independent  of  the  stored  data  organization 
when  this  is  feasible.  Similarly,  user  programs  not  concerned 
with  certain  parts  of  the  data  collection  should  not  have  to 
know  about  them,  both  for  protection  of  privacy  and  for 
simplicity  in  system  reorganization. 

Facilities  that  meet  these  requirements  are  being  investigated. 
In  addition,  earlier  work  on  the  language  is  being  reviewed 
and  improvements  are  being  considered. 

2.2  Software  System 

The  current  design  of  the  software  system  basically  corresponds 
to  the  design  documented  in  Working  Paper  No,  5  (February  29, 
1972).  Detailed  design  has  continued  as  necessary,  and  is 
discussed  in  Section  3  as  part  of  the  implementation  effort. 
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3.  Software  Implementation 

During  this  period,  implementation  of  Version  0/9  of  the 
datacomputer  was  completed.  The  basic  program  structure  is 
the  same  as  in  Version  0/8,  but  the  new  release  incorporates 
additional  capabilities.  Version  0/9  is  a  multi-user  system 
that  allows  simultaneous  access  to  shared  files.  It  includes 
minimal  updating  facilities,  improved  error  diagnostics  and 
recovery  procedures,  and  standard  initial  connection  protocol. 
The  facilities  are  described  in  detail  in  ’’Specification  for 
Datalanguage,  Version  0/9",  NIC  16446,  June  6,  1973  (see 
Appendix  of  present  report). 

3.1  Request  Handler 

The  Request  Handler  was  developed  for  Version  0/8  along  the 
lines  of  the  system  architecture  outlined  in  Working  Paper 
No.  5. 


New  in  Version  0/9  is  the  ability  to  delete  files  and  to  append 
to  files.  Every  open  data  container  has  a  user-specified  mode 
associated  with  it.  The  modes  are:  read,  write  and  append. 

An  assignment  to  a  container  whose  mode  is  write  replaces  the 
data  already  in  that  container.  If  the  mode  Is  append,  the 
new  data  is  added  to  the  end  of  the  container.  Parsing  of  the 
datalanguage  and  tuple  generation  is  essentially  the  same  In 
both  cases.  During  execution,  one  tuple  (the  Open  tuple)  sets 
up  a  pointer  to  the  beginning  location  of  the  new  data.  In 
the  write  case,  the  pointer  points  to  the  beginning  of  the 
container;  in  the  append  case,  to  the  end.  Except  for  the 
Open  tuple,  execution  of  write  and  append  assignments  is 
identical. 
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The  aatacomputer  automatically  updates  the  inversion  when  a 
file  is  updated.  Other  users  are  locked  out  until  the  update 
operation  is  complete. 

Delete  requests  are  passed  immediately  to  a  command  executor 
(CO),  which  calls  the  services  routine  to  remove  the  node 
from  the  directory.  No  parse  tree  is  generated. 

Users  can  mix  inverted  file  keys  and  non-keys  freely  in 
expressions.  Where  possible,  the  datacomputer  takes  advantage 
of  the  inversion  in  evaluating  the  expression. 

3.2  Services 
Storage  Manager 

The  storage  manager  now  recognizes  several  kinds  of  devices: 
distv,  special  disk,  and  tape.  Data  structures  have  been 
developed  for  describing  each  device,  and  the  address-mapping 
and  storage  allocation  routines  make  use  of  these  structures. 
This  was  done  in  preparation  for  adding  a  tertiary  store  as 
a  new  device. 

I/O  Manager 

Standard  initial  connection  protocol  was  implemented.  Users 
can  open  secondary  network  connections  for  the  transfer  of 
data. 


Directory  System 

Directory  nodes  can  now  be  deleted. 

The  user's  datalanguage  description  is  stored  in  the  directory. 
The  user  can  access  the  description  as  necessary.  He  can  also 
get  a  list  of  all  nodes  in  the  directory. 
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Supervisory  Functions 

The  datacomputer  runs  under  a  monitor  which  allows  for  several 
users.  These  users  share  a  database  and  can  simultaneously 
access  a  file.  To  support  this  feature,  all  the  code  has  been 
made  re-entrant. 

A  module  (OP)  has  been  added  to  provide  for  communication  with 
a  system  operator. 

Messages  have  been  divided  into  five  categories:  synchronization, 
informational,  user  error,  circumstantial  error,  and  data¬ 
computer  error.  A  code  prefixed  to  each  message  indicates  to 
the  user  program  the  category  of  each  message.  In  some  cases, 
the  code  uniquely  identifies  the  message.  These  codes  aid  the 
user  program  In  taking  appropriate  action. 

Error  recovery  procedures  have  been  added.  Depending  on  the 
seriousness  of  the  error,  these  range  from  restarting  one 
user  to  bringing  down  the  entire  datacomputer  system. 

A  dump/restore  utility  for  datacomputer  files  has  been 
implemented. 
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4.  Initial  Network  Service 


4.1  Network  Survey  Data 

The  datacomputer  provides  on-line  storage  and  data  management 
services  for  the  Network  SURVEY  program  that  runs  at  MIT 
Project  MAC.  SURVEY  attempts  to  do  a  complete  ICP  to  the 
LOGGER  socket  of  each  host  in  the  Arpanet  at  20-minute  inter¬ 
vals.  It  records  the  date,  time,  status  and  response  time  for 
each  host  and  transmits  the  data  to  the  datacomputer.  If  the 
datacomputer  cannot  accept  the  data,  it  is  held  temporarily 
at  MIT  for  later  transmission  to  the  datacomputer.  The  re¬ 
transmission  occurs  automatically. 


Another  program  a*-  MIT  generates  datalanguage  for  selective 
retrieval  of  the  SURVEY  data  from  the  datacomputer. 

Storage  of  the  SURVEY  data  at  the  datacomputer  on  a  regular 
basis  began  on  July  10,  1973. 

4.2  ETAC  Weather  Data 

Plans  are  being  made  for  storing  a  large  file  of  weather  data 
collected  by  the  United  States  Air  Force  Environmental  Technical 
Applications  Center.  In  order  to  get  operational  experience 
with  this  data,  two  small  files  have  been  loaded  using  Version 
0/9.  One  is  the  station  library,  which  has  information  about 
the  12,000  weather  stations  that  report  regularly.  The  second 
file  consists  of  one  day’s  weather  observations  from  the  entire 
world. 

These  datacomputer  files  have  been  successfully  accessed  from 
CCA.  ETAC  will  begin  using  them  shortly. 
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4.3  DECtape  FTP 

Harvard  University  Is  using  the  datacomputer  to  extend  Its 
storage  capacity.  A  user  program  running  at  Harvard  transfers 
files  between  Harvard's  disk  and  the  datacomputer.  once  on 
disk  at  Harvard,  a  file  can  be  accessed  by  other  programs 
there.  A  Harvard  user  can  save  his  updated  file  by  storing 
It  again  at  the  datacomputer.  This  facility  allows  users 
access  to  "off-line"  flies  without  manual  Intervention. 

**•4  Utilization  Statistics 

The  following  chart  Indicates  the  number  of  times  each  Network 
site  has  connected  to  the  datacomputer  In  the  present  reporting 
period  since  Version  0/9  was  rude  available  over  the  Arpanet. 
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5j _ Miscellaneous  Activities 

5.1  Seismic  Data  Working  Group 

Under  the  auspices  of  ARPA  Nuclear  Monitoring  Research  Office, 
a  seismic  data  working  group  was  formed  on  Febru?;ry  26,  1973 
"to  coordinate  work  in  progress  in  planning  the  Seismic  Data 
Acquisition,  Processing,  Analysis  and  Storage  System  required 
to  support  the  ARPA  Seismic  Verification  System". 

Membership  of  the  seismic  data  working  group  consists  of 
CCA  (data  storage),  BBN  (data  communication),  and  Teledyne 
Geotech  (processing). 

CCA  accepted  this  responsibility  as  part  of  its  present  ARPA 
contract.  During  the  present  reporting  period  six  meetings 
were  held  in  Alexandria,  Virginia  at  the  Seismic  Data  Analysis 
Center . 

CCA's  contribution  to  these  meetings  was  to  discuss  alternative 
ways  in  which  large  seismic  data  files  collected  from  stations 
around  the  world  could  be  stored  centrally  and  disseminated 
to  interested  parties.  Alternate  technical  approaches  were 
presented,  and  cost  figures  were  developed.  CCA  became 
acquainted  with  the  data  storage  and  dissemination  problems 
of  the  seismic  community. 

5.2  Technical  Presentations 

Two  major  technical  presentations  on  the  datacomputer  project 
were  given  during  this  reporting  period.  The  first  was  at 
the  EDUCOM  Spring  Conference,  devoted  to  computer  networks, 
at  Harvard  University  on  April  6,  1973.  The  second  was  at  the 
National  Security  Agency,  Ft.  Meade,  Md.  on  June  21,  1973. 
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Prof  rice 

Datalanguage  is  the  language  processed  by  the  Dataconputer,  a  data 
utility  system  being  developed  for  the  Arpanet.  The  Datacomputer 
performs  data  storage  and  data  management  functions  for  the  benefit 
of  computers  on  t he  network. 

Version  0/9  is  currently  running  at  CCA.  This  version  is  extremely 
primitive;  however#  it  does  offer  an  opportunity  for  experience 
with  t he  Datacomputer  and  with  fundamental  Datalanguage  concepts. 

Subsequent  versions  will  provide  greater  portions  of  the  full 
Datalanguage  capability#  which  has  been  described  ea-’  ier 
fUatal.inruagp .  Working  Paper  No.  3#  Datacomputer  Project#  October# 
1971#  NIC  8028).  For  example#  one  of  the  primary  restrictions  in 
0/J — elementary  data  items  must  be  fixed-length  ASCII  strings — will 
be  eliminated  in  Version  0/10#  which  is  currently  being 
implemented. 

based  on  the  experience  gained  in  the  implementation  of  these  early 
versions#  and  based  on  the  feedback  from  their  use,  a  revised 
specification  of  the  full  language  will  be  issued. 


17 


Specifications  for  Datalanguage,  Version  0/9  Page  2 


1.  introduction 

This  document  presents  a  precise  and  complete  specification  of 
Datalanguage,  Version  0/9.  It  is  organized  into  11  sections,  of 
which  this  introduction  5s  the  first.  Section  2  discusses  the 
capabilities  of  Version  0/9  in  general  terms.  Sections  3  ^.nd  4  are 
concerned  with  data  description  and  the  directory.  Sections  5 
through  is  cover  the  expression  of  data  management  operations. 
Section  M  discusses  the  recognition  of  names.  Section  10  covers 
miscellaneous  topics  and  Section  11  specifies  the  syntax  in  BI1F. 

This  specification  is  to  be  followed  with  a  user  manual,  which  will 
present  t lie  language  in  tutorial  form  and  treat  components  of  the 
Uatacomputer-user  interface  -.ther  than  the  language. 


2.  Capabilities  of  Version  0/9 

Version  0/9  of  Datalanguage  has  capabilities  for  the  storage  of 
files;  for  addition  of  data  to  existing  files,  and  for  the  deletion 
of  files.  Retrievals  can  output  whole  files  as  well  as  subsets  of 
files.  Data  can  be  selected  from  files  by  content,  using 
expressions  formed  from  boolean  and  inequality  operators. 

At  the  option  of  the  file  creator,  an  inversion  is  constructed  and 
maintained  by  the  Datacomputer .  The  inversion  increases  the 
efficiency  of  selective  retrieval,  at  the  cost  of  storage  space  and 
file  maintenance  effort.  Users  other  than  the  file  creator  need 
not  be  aware  of  the  existence  of  the  inversion,  or  of  which  fields 
are  inverted  file  keys.  The  language  is  designed  so  that  they 
state  the  desired  result  of  a  retrieval,  and  the  Datacomputer  uses 
the  inversion  as  much  as  the  request  permits. 

Elementary  data  items  are  fixed-length  ASCII  strings.  Files  are  a 
restricted  class  of  hierarchical  structures. 

Many  of  the  restrictions  mentioned  in  this  memo  will  be 
short-1 i ved.  In  particular,  those  statements  followed  with  3 
asterisks  £***)  refer  to  restrictions  that  will  be  considerably 
weakened  or  eliminated  entirely  in  t  he  next  version  of  the 
software . 
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3.  Data  Description 

A  containpr  is  a  variable  whose  value  is  a  data  object  of  general 
character  and  arbitrary  size  (In  Version  0/9#  size  is  restricted. 
See  section  3.4).  Examples  of  containers  which  are  implemented  in 
other  systems  are  files#  records#  fields#  groups#  and  entries. 

The  container  is  distinct  from  the  data  in  the  container.  For 
example#  soace  al location  is  an  operation  on  a  container,  while 
changing  the  un 1 t  price  field  from  25  to  50  is  an  operation  on  data 
in  a  container. 

\  container  nay  enclose  other  containers.  When  a  container  is  not 
enclosed  by  another  container#  it  is  said  to  be  outermost .  if 
conf.ainer  A  encloses  container  1 i#  and  no  other  container  in  A  also 
encloses  0#  then  A  immediately  encloses  B. 

A  Uatal anguage  description  is  a  statement  of  the  properties  of  a 
conta i ner . 

All  containers  have  the  attributes  ?  dent  and  type .  I  dent  is  a 
character  string  by  which  users  refer  to  the  container.  Type 
determines  the  form  of  the  container's  value;  the  value  can  be 
elementary,  or  it  can  consist  of  other  containers.  There  are  3 
types:  LIST#  STRUCT#  and  STRING(***).  A  LIST  contains  a  group  of 
containers  having  the  same  description.  A  STRUCT  contains  a  group 
of  containers#  each  of  which  has  its  own  description.  A  STRING  is 
a  sequence  of  ASCII  characters.  While  a  STRING  is  not  really  an 
elementary  item,  it  is  handled  as  one  in  Version  0/9. 

Certain  containers  can  have  other  attributes.  An  outermost 
container  has  a  function.  The  function  attribute  specifies  whether 
the  container  is  to  be  used  for  storage  or  for  transmission. 

S i 7P  is  some  meaningful  dimension  of  the  container#  which  is 
type-dependent.  It  is  used  for  space  allocation  and  data  stream 
pars i ng . 

An  aggregate  container  (i.e.#  one  that  contains  other  containers) 
has  us  an  attribute  the  description  or  descriptions  of  its 
components.  Thus  if  S  is  a  STRUCT  containing  A#  B#  and  C#  then  the 
descriptions  of  A#  B,  and  C  are  attributes  of  S. 

A  STRING  defined  in  certain  contexts  can  have  an  inversion 
attribute.  This  is  an  access  property  that  is  not  really  local  to 
the  STRING#  but  is  associated  with  it  for  convenience. 

3.1  Ident 

The  ident  of  a  container  is  composed  of  al phanumer i c 
characters#  the  first  of  which  is  alphabetic.  It  may  not 
consist  of  more  than  100  characters. 
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The  elements  of  a  STRUCT  must  have  idents  unique  in  the  STRUCT. 

3.2  Function 

The  function  of  a  container  is  either  FILE#  PORT#  or  TEMPORARY 
PORT.  When  the  function  is  FILE#  then  the  container  is  used 
for  storage  of  data  at  the  Datacomputer .  When  the  function  is 
PORT#  then  t lie  container  is  used  for  transmission  of  data  into 
or  out  of  the  Datacomputer.  When  the  function  is  TEMPORARY 
PORT  (which  may  be  abbreviated  TEMP  PORT)#  the  container 
behoves  like  a  PORT;  however#  its  description  is  not  retained 
in  the  Datacomputer  beyond  the  session  in  which  it  is  created. 

5.3  Type 

Type  is  one  of:  LIST#  STRUCT#  or  STRING.  These  are  defined  on 
the  preceding  page. 

in  it;  occurrence  of  a  STRUCT#  the  elements  appear  in  the  order 
in  which  their  descriptions  appear  in  the  STRUCT  description. 
All  elements  are  present  in  each  occurrence  of  the  STRUCT. 

An  element  of  a  STRUCT  or  LIST  can  be  a  container  of  any 
datatype.  However#  Uifi  PUtftrfflQSt  tuantflJl  nfif  must  ]*£  £ 

I„1S.T.(***) . 

3.4  Size 

The  size  of  a  STRING  is  the  number  of  characters  in  it.  The 
size  of  a  STRUCT  is  not  defined  (***).  The  meaning  of  the  size 
of  a  LIST  depends  upon  other  properties  of  the  LIST  (***). 

Ordinarily#  the  size  of  a  LIST  is  the  number  of  L I ST-members . 
An  exception  is  the  case  of  the  outermost-L I  ST .  In  an 

outermost-L I  ST  with  a  function  of  FILE#  the  size  is  the  number 
of  LIST-members  for  which  space  should  be  allocated.  When  no 
size  is  present  in  this  case#  the  system  computes  a  default. 

In  an  outermost-L I  ST  with  a  function  of  PORT#  the  size  is 

ignored  (***). 

Only  outermost  containers  may  be  larger  than  a  TENEX  page  (2560 
ASCII  characters) (***) . 

7.5  Inversion 

An  inversion  is  an  auxiliary  data  structure  used  to  facilitate 
retrieval  by  content. 

Its  basic  application  is  the  fast  retrieval  of  sets  of 

outernost-L IST-members  (this  can  be  extended  to  other  container 
sets,  and  wi 1 1  be  after  release  1).  Consider  a  list  of  weather 
observations,  stored  as  a  file  on  the  Datacomputer.  If  quick 
retrieval  of  observations  by  COUNTRY  is  desired,  then  this  is 
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indicated  in  the  description  of  the  COUNTRY  container. 
According  to  common  usage  in  information  retrieval#  this  makes 
COUNTRY  a  kev  in  tiie  retrieval  of  observations. 

Note  that  the  inversion  option  only  affects  the  efficiency  of 
retrieval  by  COUNTRY#  not  the  ab  i  1  i tv  to  retrieve  by  COUNTRY. 

There  are  restrictions  on  use  of  the  inversion  option.  First# 
it  can  be  applied  only  to  STRINGS.  Second  a  STRING  having  the 
inversion  option  must  occur  only  once  in  each 
outermost-LIST-member.  Third#  it  is  ignored  when  applied  to 
STRINGS  in  PORT  descriptions. 

Eventually  there  will  be  several  types  of  inversion  option;  in 
Version  0/9  there  is  only  the  1 D *  option  (for  distinct). 


3.0  Syntax 

The  description  is  simply  an  enumeration  of  properties;  these 
properties  are  specified  in  the  order: 

<ident>  <function>  <type>  <size>  <other> 

Properties  which  do  not  apply  are  omitted. 

An  example: 

'  F  FILE  LIST  (25)  A  STR  ( 1U ) 

Here  1 F *  is  the  <ident>#  ’FILE'  is  the  <function>#  'LIST'  is 
the  <type>#  '(25)'  is  the  size#  and  'A  STR  (10)'  is  the  <other> 
of  one  description.  Of  course#  'A  STR  (10)'  is  itself  another 
description:  the  description  for  members  of  the  LIST  named  F. 

An  example  of  a  complete  description  for  a  file  of  weather 
observations  keyed  on  location: 

WEATHER  FILE  LIST 

OBSERVATION  STRUCT 

LOCATION  STRUCT 

CITY  STR  (10)#  i-D 
COUNTRY  STR  (10)#  l-D 
END 

TIME  STRUCT 

YEAR  STR  (2) 

DAY  STR  (3) 

HOUR  STR  (2) 

END 

DATA  STRUCT 

TEMPERATURE  STR  (3) 

RAINFALL  STR  (3) 

HUMIDITY  STR  (2) 

END 

21 
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END 

The  ENDs  are  needed  to  delimit  the  list  of  elements  of  a 
STRUCT.  I -D •  indicates  that  the  string  is  to  be  an 
inversion  key  for  the  retrieval  of  outermost-L I ST-members . 
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4.  Directory 

The  directory  is  a  system  ftle  in  which  the  names  and  descriptions 
of  all  user-defined  containers  are  kept. 

The  directory  is  structured  as  a  tree.  Each  node  has  an  ident, 
which  need  not  be  unique.  There  is  a  single  path  from  the  root  of 
the  tree  to  any  node.  The  idents  of  the  nodes  along  this  path  are 
concatenated,  separated  by  periods,  to  form  a  pathname,  which 
unambiguously  Identifies  the  node  (e.g.,  A.B.C  could  be  a  pathname 
for  node  with  an  ident  of  C). 

In  a  la  or  version  of  the  software,  the  directory  will  be 
generalized  to  provtde  for  links  between  nodes,  so  that  it  will  not 
properly  be  a  tree.  For  now,  however,  the  tree  model  is  convenient 
and  adequate. 

A  node  may  represent  a  container,  or  it  may  simply  hold  a  place  in 
the  space  of  pathnames.  When  it  represents  a  container,  it  cannot 
(currently)  have  subordinate  nodes. 

Eventually,  it  is  planned  to  model  the  directory  as  a  structure  of 
containers,  with  its  description  distributed  throughout  the 
structure.  Host  operations  defined  on  the  directory  will  be 
defined  on  user  data,  and  vice  versa.  Access  privileges  and 
privacy  locks  will  be  part  of  the  data  description  and  will 
likewise  be  applicable  both  to  directory  nodes  and  data  structures 
below  the  node  level. 

4.1  CREATE 

A  CREATE- request  either:  (a)  ados  a  node  to  the  directory, 
optionally  associating  the  description  of  either  a  PORT  or  a 
FILE  with  the  node,  or  (b)  creates  a  temporary  container  which 
is  riot  entered  in  the  directory,  but  has  a  description  and  can 
be  referenced  in  requests.  If  the  description  defines  a  file, 
CREATE  causes  space  to  be  allocated  for  the  file. 

To  create  a  node  with  a  description: 

CREATE  <pathname>  <descr  i  pt  i  on>  ; 

To  create  a  node  with  no  description: 

CREATE  <pathnane>  ; 

Note  that  the  description  determines  whether  or  not  the 
container  is  temporary  (see  section  3.2  for  details). 

A  CREATE-request  adds  a  single  node  to  the  directory.  Tiros  to 
add  CCA. RAW. F  to  an  empty  directory,  three  requests  are  needed: 
CREATE  CCA  ; 

CREATE  CCA. RAW  ; 

CREATE  CCA. RAW. F  ; 

Notice  that  the  last  ident  of  the  pathname  doubles  as  the  first 
ident  of  the  description: 

CREATE  CCA. RAW. G  FILE  L I  ST  A  STR  (5)  ; 

0  i 
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That  is,  G  is  both  the  ident  of  a  node  and  the  ident  of  an 
outermost  container  of  type  LIST. 

4.2  Delete 

A  DELETE-request  deletes  a  tree  of  nodes  and  any  associated 
descriptions  or  data.  The  syntax  is: 

DELETE  <pathname>  ; 

The  named  node  and  any  subordinates  are  deleted. 

Dote  that  to  delete  data  while  retaining  the  directory  entry 
and  description,  DELETE  should  not  be  used  (see  section  6.3  for 
the  proper  method). 

4.3  LIST 

The  LIST-request  is  used  to  display  system  data  of  interest  to 
a  user.  It  causes  the  data  specified  to  be  transmitted  through 
the  Datalanguage  output  port. 

Several  arguments  of  LIST  apply  to  the  directory.  LIST  |ALL 
transmits  all  pathnames  in  the  directory.  LIST  £ALL. f^SOURCE 
transmits  all  descriptions  in  the  directory.  Instead  of  £ALL, 
a  pathname  can  be  used: 

LIST  <pn> . £ALL 

Lists  pathnames  subordinate  to  <pn>. 

LIST  <pn> . ^SOURCE 

lists  descriptions  subordinate  to  the  node  represented  by  <pn>. 
For  details  about  the  LIST-request,  see  section  10.1. 
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5.  Opening  and  closing  containers 

Containers  must  be  open  before  they  can  be  operated  on. 

A  container  is  open  when  it  is  first  created.  It  remains  open 
until  closed  explicitly  by  a  CLOSE-request  or  implicitly  by  a 
DELETE-request  or  by  session  end. 

A  closed  container  is  opened  by  an  OPEN-request .  A  temporary 
container  is  always  open;  a  CLOSE-request  deletes  it. 

5.1  Modes 

An  open  container  has  a  mode/  which  is  one  of:  READ,  WRITE/  or 
APPEND.  The  mode  determines  the  meaning  and/or  legitimacy  of 
certain  operations  cn  the  container. 

The  mode  is  established  by  the  operation  which  opens  the 
container.  It  can  be  changed  at  any  time  by  a  MODE-request . 

A  CREATE  leaves  the  container  in  WRITE  mode.  An  OPEN  either 
specifies  the  mode  explicitly  or  implicitly  sets  the  mode  to 
READ . 

5.2  Syntax 

To  open  a  container: 

OPEN  <pathname>  <mode>  ; 
or: 

OPEN  <pathname>  ; 

where  <mode>  is  defaulted  to  READ. 

To  close  a  container: 

CLOSE  <ldent>  ; 

where  <ident>  is  the  name  of  an  outermost  container. 

Two  containers  with  the  same  outermost  <ident>  can  not  be 
opened  at  the  sanle  tine  (***). 

To  change  the  mode  of  an  open  container: 

MODE  <ident>  <newmode>  ; 


5.3  LIST 


LIST  50PEN  transmits  name/  mode  and  connection  status  of  each 
open  outermost  container  through  the  Datalanguage  output  port. 
(The  Datalanguage  output  port  is  the  destination  to  which  all 
Datacomputer  diagnostics  and  replies  arc  sent.  !t  is 
established  when  the  user  initially  connects  to  the 
Datacomputer.)  For  details  of  the  L I  ST- request /  see  section 
10 . 1 . 
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0.  Assignnent 

Assignment  transfers  data  from  one  container  to  .another. 

The  equal  sign  ('  =  ')  is  the  symbol  for  assignment.  The  value  of 
the  operand  on  the  right  of  the  equal  sign  is  transferred  to  the 
operand  on  the  left.  (Eventually#  both  operands  will  be 
weakly-restricted  Uatalanguage  expressions#  which  may  evaluate  to 
sets  as  well  as  to  single  containers.  Now#  the  left  must  be  a 
container  name#  the  right  may  be  a  container  name  or  a  constant.) 

Assignnent  is  defined  for  all  types  of  containers.  When  the 
containers  are  aggregates#  their  elements  are  paired  and  data  is 
transferred  between  paired  elements.  Elements  of  the  target 
container  that  do  not  pair  with  some  source  element  are  handled 
with  a  default  operation  (currently  they  are  filled  wi  tli  blanks). 

The  operands  of  an  assignment  must  have  descriptions  that  match . 
The  idea  of  match i ,ie  is  that  the  descriptions  must  be  similar 
enough  so  that  it  is  obvious  how  to  map  one  into  the  other. 

b.l  Conditions  for  legitimate  assignment 

Assignment  must  reference  objects#  not  sets.  An  object  is: 

(a)  an  outermost  container#  or 

(b)  a  constant#  or 

(c)  in  the  body  of  a  F0R-loopL.  either 

(cl)  a  member  of  a  set  defined  by  a  FOR-QPERAND,  or 
(c2)  a  container  which  occurs  once  in  such  a  member 


In  t lie  case  of  a  reference  of  type  (cl)#  the  object  referenced 
is  taken  to  be  the  current  member.  In  the  case  of  (c2)#  the 
object  referenced  is  that  which  occurs  in  the  current  member. 
Ti» i s  is  explained  further  in  section  7. 

The  left  operand  of  an  assignment  is  subject  to  further 
restriction.  If  it  is  an  outermost  container#  it  must  be  open 
in  either  WRITE-  or  APPEND -mode .  If  it  is  not  an  outermost 
container#  then  the  reference  is  of  type  (c)#  which  means  that 
some  FUR-operond  has  established  a  context  in  which  the 
assign-operand  is  an  object.  The  FOR-operand  which  establishes 
this  context  must  be  the  output-operand  of  the  FOR. 


When  the  ass i gn -ope rand  is  an  outermost  container#  it  must  be 
open.  Such  an  operand  must  be  referenced  by  Its  simple 
container  ident(***)#  not  its  directory  pathname. 


In  the  body  of  a  loop  nested  in  one  or  more 
assignments  are  further  restricted#  due  to  a  0/3 
problem,  bee  section  7.2  for  details. 

26 


other  loops# 
i  np  I  enien  tali  on 


pec i fi cat  ions  for  Data  1 anguage# 


Version  0/9 


Page  11 


Finally#  t he  descriptions  of  the  operands  must  natch.  If  one 

is  a  constant#  then  the  other  must  bo  a  STRING(***).  If  both 

are  containers#  then  in  the  expression: 

A  =  B ; 

the  descriptions  of  containers  A  and  B  match  if: 

1.  A  and  U  have  the  same  typo 

2.  if  A  and  B  are  LISTs#  then  they  have  equal  numbers  of 
LI ST-membe rs#  or  else  A  is  an  outernost-LI ST. 

3.  if  A  and  d  are  aggregates#  then  at  least  one  container 

immediately  enclosed  in  A  matches#  and  has  the  same  ident 
as#  one  container  immediately  enclosed  in  ii. 

b.2  Result  of  assignment 

If  the  operands  are  STRINGS#  then  the  value  of  B# 

left-justified#  replaces  the  value  of  A.  If  B  is  longer  than 
A#  the  value  is  truncated.  If  U  is  shorter  than  A#  then  A  is 
f’lled  on  the  right  with  blanks  as  necessary. 

If  the  operands  are  STRUCTs#  then  assignment  is  defined  in 
terms  of  the  STRUCT  members.  If  a  member  of  A#  jtjA#  matches  and 

hi  s  the  same  name  as  a  member  of  B#  cB#  then  nB  is  assigned  to 

£iA .  If  no  such  exists#  then  £qA  is  filled  with  blanks. 

If  the  the  operands  are  LISTs,  the  result  depends  on  several 
factors.  First#  notice  that  the  descriptions  of  the 
LIST-nembers  must  natch;  otherwise  the  assignment  would  not  be 
legitimate  by  the  matching  rules  of  0.1. 

If  A  is  an  outornost-L I  ST#  then  it  can  be  in  either  of  two 
nodes:  WRITE  or  APPEND.  If  A  is  in  WRITE-mode#  its  previous 

contents  are  first  discarded;  it  is  then  landled  as  though  it 

wore  in  APPEND-mode. 

If  A  is  not  an  outermost-L I  ST#  then  it  is  always  effectively  in 
WR I TE-node . 

After  taking  the  mode  of  A  into  account#  as  described  above# 
the  procedure  is: 

for  each  member  of  LIST  B 

(a)  add  a  new  member  to  t ho  end  of  A 

(b)  assign  the  current  member  of  B  to  the  new  member  of  A 

0.3  Deletion  of  Data  Through  Assignment 

If  A  is  an  outermost  container  in  WRITE-mode#  and  B  is  a 
container  with  description  that  matches  A#  and  if  B  contains  no 
data#  then  A=B  has  the  effect  of  deleting  all  data  from  A. 
Note  that  if  A  is  in  APPEND-mode  In  these  circumstances#  then 
A=B  is  a  no-operation  (i.e.#  has  no  effect). 

27 
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7.  FOU 

FOR  <output  set  spec>  ,  < input  set  spoc>  <body>  END  ; 

Tlie  output  set  is  optional:  that  is,  FOR  need  net  produce  output, 
w'lien  the  output  set  is  omitted,  the  syntax  is: 

FOR  < input  set  spec>  <body>  END  ; 

The  operations  specified  in  t ho  body  are  performed  once  for  each 
member  of  the  input  set.  References  in  the  body  to  the  input  set 
member  are  treated  as  references  to  the  current  input  set  member. 

Jhen  an  output  set  is  present,  a  new  member  is  created  and  added  to 

the  output  set  for  each  iteration  (i.e.,  for  each  input  set 
member).  References  to  the  output  set  member,  similarly,  are 
treated  as  references  to  the  cur  rent  output  set  member. 

The  output  set  spec  must  be  the  name  of  a  LIST  member.  Each 

iteration  of  the  FOR  will  create  one  such  member,  and  add  it  to  its 
LIST  (hereafter  called  the  output  LIST).  The  body  determines  the 
value  that  the  new  member  receives.  Any  STRING  in  the  new  member 
which  is  not  given  a  value  by  the  body  receives  the  default  value 
of  all  blanks. 

Tiie  input  set  s.iec  must  be  an  expression  evaluating  to  a  set  of 
LI ST-menbcrs  (see  section  7.1  for  details  of  input  set 
specification).  Each  iteration  of  the  FOR  will  input  one  such 
member;  the  FOR  will  terminate  when  each  member  of  the  set  has  been 
processed.  The  LIST  from  which  the  input  set  members  are  drawn  is 
cal  led  tiie  ? nput  LIST. 

FOR  is  effectively  a  means  of  accomplishing  variants  of  assignment 
between  a  pair  of  LISTS.  FOR  is  less  concise  than  assignment,  but 
offers  more  flexibility.  Its  advantages  are: 

(a)  not  all  the  input  L I  ST-menle  rs  need  be  transferred  to  tiie 
output  LIST.  A  subset  can  be  selected  by  content. 

(b)  1 1 io  user  has  explicit  control  over  the  assignment  of  values  to 

output  L I ST-nembers .  ^ 

CO 
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This  is  riost  easily  understood  by  an  example: 


P  PORT  LIST 
i!  JTKuCT 
a  t>TR 
C  STR 
EI10 


F  FILE  LIST 
R  STRUCT 
A  STRUCT 
A1  STR 
A2  STR 
B  STR 
C  STR 
END 


(1) 

P  ■  F  ; 

CM 

FOR  P.R 

P.U  =  F.R  ; 

END  ; 

(3)  FOR  P.R,  F.R  WITH  A1  ED  * XY '  OR  A2  GE  'AB' 
B  =  C  ; 

C  =  A2  ; 

END  ; 


Here,  (1)  and  (2)  are  entirely  equivalent  requests.  However,  (3) 
is  quite  different  and  is  not  expressible  as  assignment.  It 
selects  a  subset  of  the  F.Rs.  The  values  it  gives  to  the  P.Rs 
could  not  result  from  application  of  the  matching  rules  to  F  and  P. 

because  FOR  is  effectively  assignment  between  a  pair  of  LISTs,  the 
LISTs  referenced  by  a  legitimate  FOR-operat i on  are  largely  subject 
to  the  same  restrictions  as  LISTs  referenced  in  an  assignment.  One 
exception  is  that  the  descriptions  of  the  LIST-members  need  not 
match . 

These  restrictions  are; 

(a)  both  LISTs  must  be  objects  in  the  context  in  which  the  FOR 
appears . 

(b)  both  LISTs  must  be  open  or  contained  in  open  outermost 
contai ners 

(c)  if  the  output  LIST  is  an  outermost  container,  it  must  be  in 
WRITE-  or  APPEND-nodc. 

(d)  If  the  ouput  LIST  is  not  outermost,  the  LIST  which  most 
immediately  encloses  it  must  be  the  output  LIST  of  an  enclosing 
FUR. 

The  node  of  the  output  LIST  of  the  FOR  affects  the  result  much  as 
it  would  in  an  assignment:  that  is,  a  FOR  outputting  to  a  LIST  in 
W°ITE-node  overwrites  previous  contents,  while  a  FOR  outputting  to 
a  u'ST  in  APPEND-node  adds  to  previous  contents. 
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r.AiiT 1 1 lfi  Til  Tit£  RFADFR:  For  convenience/  these  specifications  use 
phrases  such  as  'LISTs  referenced  by  a  FOR'.  Recall  that  such  a 
phrase  is  not  literally  correct/  in  the  sense  that  the  operands  of 
a  FOR  are  always  LIST  members .  not  LISTs. 

7.1  Details  of  input  set  specification 

Tiie  input  set  is  specified  by  a  Datalanguage  expression  that 
evaluates  to  a  set  of  L I ST-nembers .  Such  an  expression  can  be 
sinply  the  set  of  all  members  of  a  LIST,  or  it  can  be  a  subset 
of  the  members  of  a  LIST/  specified  by  content.  For  example, 
with  t he  description: 

F  FILE  LIST 

R  STRUCT 

A  STR  (1) 

B  STR  (1) 

END 

the  expression: 

F.R 

references  all  R’s  on  tiie  LIST  .  However: 

F.R  WITH  A  EQ  '5' 

references  only  those  R's  containing  an  A  having  the  value  '5'. 
The  expressions  permitted  as  input  set  specifications  are  of 
tiie  form: 

< 1 i st -nember-name>  WITH  <boolexp> 

The  <boolexp>  is  constructed  of  comparison  expressions  joined 
by  t he  Boolean  operatorsAND  and  OR.  Any  expression  can  be 
negated  with  NOT. 

Comparison  operators  have  the  highest  precedence.  Next  highest 
is  AND,  then  OR,  then  HOT. 

The  comparison  expressions  are  restricted  to  the  form: 

<co;itainer  name)  <comop>  <constant> 
where : 

(a)  <constant>  is  a  string  constant  enclosed  in  single  quotes 
(see  section  10.2  for  a  discussion  of  constants) 

( b )  <conop>  is  one  of  six.  operators: 

EQ  equal 

NE  not  equal 

LT  less  than 

GT  greater  than 

LE  less  than  or  equal  to 

GE  greater  than  or  equal  to 

(c)  “(container  name)  is  the  name  of  a  STRING  that  appears  once 
in  eacli  L  I  ST-nember . 

The  constant  is  truncated  or  padded  with  blanks  on  the  right  to 
make  it  equal  in  size  to  tiie  container  to  which  it  is  being 
compared.  Notice  that  padding  on  the  right  is  not  always 
desirable  (users  will  have  control  over  the  padding  in  a  future 
release).  In  particular,  care  must  be  excercised  when  using 
numbers  in  Version  (J/9.  (A  number  represented  as  a  STRING 
should  actually  be  described  as  a  number;  eventually  It  will  be 

o  0 
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possible  to  do  tnis}. 

7.2  FOR-body 

Two  operations  are  legitimate  in  a  FOR-body:  FOR  and 

assignment . 

These  are  subject  to  the  restrictions  discussed  in  Section  6.1 
and  in  the  introduction  to  Section  7.  The  restrictions  are 
related  to  three  requirements:  (1)  that  the  names  be 
recognizable  (see  Section  9  for  details)/  (2)  that  a  request  be 
consistent  regarding  direction  of  data  transfer  between 
containers/  both  within  itself  and  with  the  MOO E  of  outermost 
containers/  and  (3)  that  transfers  occur  between  objects,  not 
sets  of  objects.  The  first  two  requirements  are  permanent/  but 
will  become  weaker  in  later  versions  of  the  language.  The  last 
requirement  is  temporary  and  will  be  present  only  in  early 
versions. 

Rue  to  an  implementation  problem  associated  with  Version  0/9/ 
there  is  a  somewhat  bizarre  restriction  applied  to  references 
made  in  the  body  of  a  loop  nested  in  another  loop.  This 
restriction  is  not  expected  to  pose  any  practical  problems  for 
users#  and  is  not  part  of  the  language  design,  but  is  discussed 
here  for  completeness. 

The  restriction  is  most  easily  understood  by  example: 

given  the  description 
F  LIST 

R  STRUCT 

A  STR  (3) 

DL  LIST  (3) 

0  STR  (3) 

C  STR  (3) 

END 

and  the  request  fragment: 

FOR  ...,R 

FOR  .  ..,B 


END 


observe: 

(a)  The  outer  loop  processes  the  set  of  R's  in  F. 

(b)  For  each  R  in  F,  the  inner  loop  processes  the  set  of  B's  i r. 
the  BL  contained  in  that  R. 

(c)  In  the  body  of  the  inner  loop,  there  are  references  to  A 
and  C,  which  do  not  occur  in  B,  but  do  occur  In  R.  That 
is,  the  objects  referenced  in  the  inner  looo  body  are 
defined  by  the  outer  loop,  not  the  inner  loop.  In  general, 
this  is  fine;  in  the  case  of  C,  however,  we  have  a  problem. 
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(ti)  C  occurs  bevond  the  end  of  CL. 

The  0/9  conpiler  is  capable  of  neither  (1)  looking  ahead  enough 
to  locate  C  before  it  conpiles  code  for  the  loop#  nor  (2)  while 
generating  code  to  loop  on  the  G's  in  CL#  generating  a  separate 
body  of  code  that  skips  to  the  end  of  CL  to  locate  C.  Thus  it 
can  handle  A#  whicli  has  been  located  before  it  begins  loop 
generation#  but  it  cannot  handle  C#  which  requires  a  little 
foresight. 

The  request  fragment  shown  would  not  cause  problems  if  the 
description  were  changed  to: 

F  LIST 

it  STRUCT 

A  STR  (3) 

C  STR  (3) 

CL  LIST  (3) 

C  STR  (3) 

END 

Then  both  A  and  C  would  have  been  found  before  code  for  the 
inner  loop  was  generated. 

v; 

kj  L. 
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o.  Data  Transmission 

Jutu  is  transferred  from  container  to  container  by  execution  of 
assignment  and  FOR  operations.  The  outermost  containers  involved 
in  transfers  can  bo  files  or  ports.  If  both  are  files#  then  the 
transfer  is  internal  to  the  Datacomputer .  If  either  is  a  port# 
then  an  address  in  t lie  external  world  is  needed  to  accomplish  the 
data  transmission. 

Juch  an  address  is  supplied  through  a  CONNECT-request,  which 
associates  a  container  (having  a  function  of  PORT)  with  an  external 
add  ress : 

CONNECT  < i den t>  TO  <addross>  ; 

Here  <address>  is  either  a  specification  of  host  and  socket  number, 
or  a  TENEX  file  designator  (for  CCA's  TENEX)  enclosed  in  single 
quotes.  The  host  and  socket  form  is: 

< socket)  AT  <host> 

where  <socket>  is  a  decimal  number,  and  host  is  either  a  decimal 
number  or  a  standard  host  name  (since  standard  host  names  don't 
exist  right  now,  it  lias  to  hr  the  TENEX  'standard'  name  for  the 
host.  Contact  the  author  for  the  latest  list.)  If  <host>  is 
omitted,  it  is  taken  to  be  the  host  from  which  the  Natal anguage  is 
being  transmitted. 

The  address  associated  with  a  port  cari  he  changed  by  issuing 
another  CONNECT-request . 

A  [)  I  iiCUIINECT- request  simply  breaks  an  existing  port/address 
association  without  establishing  a  new  one.  (A  CLOSE- request  that 
references  an  open  port  executes  a  DISCONNECT.)  The  syntax  of 
DISCONNECT  is: 

DISCONNECT  <idcnt>  ; 

A  port  is  disconnected  when:  (a)  no  successful  CONNECT-request  lias 
ever  been  issued  for  it,  or  (b)  a  DISCONNECT  for  the  port  has  been 
executed  since  the  last  successful  CONNECT. 

When  a  disconnected  port  is  referenced  in  an  assignment,  it  is 
connected  by  default  either  to: 

(a)  the  connection  used  for  the  transmission  of  Natal angauago  to 
the  Datacomputer,  or 

(b)  the  connection  used  for  the  transmission  of  Datacomputer 
diagnostics  to  the  user 

The  choice  between  (a)  and  (b),  of  course,  depends  on  whether  the 
reference  is  for  input  or  output.  These  connections  arc 
established  by  the  network  user's  ICP  to  the  Datacomputer  at  the 
beginning  of  the  session. 

Note  mat  CONNECT  arid  DICCi'NNECT  do  not  open  files  or  network 
connections.  They  simply  make  address  associations  within  the 
Datacomputer.  The  files  and  connections  are  opened  before  each 
request  and  closed  after  each  request. 


Specifications  for  Data language,  Version  0/9 


Page  13 


9.  Names  in  Natal  anguage 

A  nane  is  recoen  i  zed  when  it  has  been  associated  with  a  particular 
data  container  or  set  of  containers. 

Datal  anguage  has  Mechanisms  for  the  recognition  of  names  in 
contexts.  That  is,  the  meaning  of  t he  name  is  related  to  where  it 
appears . 

This  makes  it  possible  to  attach  natural  meanings  to  partially 
pual i f ied  names . 

For  example: 

WEATHER  FILE  LIST 

STATION  STRUCT 

CITY  STM  (IS) 

STATE  STR  (IS) 

DATA  LIST  (24) 

OBSERVATION  STRUCT 
HOUR  STR  (2) 

TEMPERATURE  STR  (3) 

HUMIDITY  STR  (2) 

PRESSURE  STR  (4) 

END 

EMI) 

RESULTS  PORT  LIST 

RESULT  STRUCT 

CITY  STR  (15) 

HOUR  STR  (2) 

TEMPERATURE  STR  (3) 

END 

FUR  STATION  WITH  STATE  EQ  'CALIFORNIA' 

FOR  RESULT,  OBSERVATION  WITH  HOUR  GT  '12' 

AND  HUMIDITY  LT  '75' 

CITY  =  CITY  ; 

HOUR  =  HOUR  ; 

TEMPERATURE  =  TEMPERATURE  ; 

END  ; 

END  ; 

in  the  assignment  'CITY  =  CITY',  the  first  CITY  is  understood  to  ho 
RESULT. CITY  and  the  second  is  understood  to  be  STAT I  ON . C I TY . 
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9.1  Informal  Presentation  of  Recognition  Rules 

'Ident*  is  used  in  the  sense  of  section  3.  for  example#  in  the 
description: 

r  FILE  LIST  R  STRUCT  A  STR  Cl)  B  STR  (1)  END 
F #  R#  A  and  B  are  idents. 

A  context  is  a  tree  whose  nodes  are  *  dents.  In  such  a  tree# 
the  terminal  nodes  are  idents  of  STRlIJGs.  The  ident  of  a  LIST 
is  superior  to  the  ident  of  the  L I ST-mernber .  The  Ident  of  a 
STRUCT  is  superior  to  the  idents  of  the  STRUCT  elements.  The 
context  whose  top  node  is  F  is  said  to  be  the  context  of  £. 


+ - + 

!  P  t 


+ 


+ 


+ - + 


1  R  ! 
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+ 
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! 


+-----+ 
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j 


+  - - -  + 


!  A  ! 


+-----+ 


!  B  ! 


+ - + 


Figure  9.1-1  The  context  of  F 


A  pathname  is  a  sequence  of  idents#  naming  nodes  along  a  path 
from  one  node  to  another.  A  ful 1  pathname  in  the  context 
starts  at  the  topmost  node.  Thus  F.R.B  is  a  full  pathname  in 
tiie  context  of  F.  A  partial  pathname  starts  at  a  node  other 
than  the  topmost  node  (e.g>  R.B#  B), 

in  Datal anguage#  pathnames  omitting  intermediate  nodes#  such  as 
F.D  (which  omits  'R')#  ore  not  permitted.  Thus  partial 
pathnames  are  partial  only  in  that  additional  names  are  implied 
on  tiie  left.  _ 
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Three  attempts  at  recognition  of  a  pathname#  PN#  in  a 
CX#  are  made: 

(a)  recognition  of  PN  as  a  full  pathname  in  CX 

(b)  recognition  of  PN  as  a  partial  pathname  in  which 
topmost  node  of  CX  is  omitted 

(c)  recognition  of  PN  as  an  arbitrary  partial 
occurring  only  once  in  CX. 


- 1 fta  "'•f  ' 

context# 

only  the 
pathname 


The  attempts  are  made  in  the  above  order#  and  the  recognition 
process  halts  with  the  first  successful  attempt. 


Specifications  for  Datalanguage,  Version  0/9 


Page  21 


As  an  example,  consider  the  description: 

F  FILE  LIST 

R  STRUCT 

A  STR 
[ i  STR 
S  STRUCT 

R  STR 

which  defines  the  context  in  Figure  9.1-2. 
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!  R  ! 


Figure  9.1-2  Example  Context 


In  this  context,  F.K.A  is  a  full  pathname.  Thus,  F.R.A  is 
recognized  in  attempt  (a).  R  is  a  partial  pathname  in  which 
only  the  topmost  node  is  omitted.  Thus  R  is  recognized  in 
attempt  (b).  Mote  carefully  that  R  is  recognized  as  a 
reference  to  F.R,  not  to  F.R.S.R.  Finally,  B  is  an  arbitrary 
partial  pathname  occurring  only  once  Iri  the  context.  Thus  B  is 
recognized  in  attempt  (c). 

Two  stacks  of  contexts  are  maintained:  one  for  names  used  in  an 
input  sense,  and  one  for  names  used  in  an  output  sense.  When  a 
name  is  to  be  recognized,  it  is  first  decided  whether  the 
reference  is  rn  input  reference  or  an  output  reference.  An 

3  J 
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input  reference  is  (a)  the  right  hand  operand  of  an  assign/  or 
Cb)  a  name  in  the  input  set  spec  of  a  FOR.  An  output  reference 
is  (a)  the  left  operand  of  an  assign/  or  Cb)  the  output  operand 
of  a  FOR.  The  first  context  on  the  appropriate  context  stack 
is  then  searched/  according  to  the  procedure  outlined  on  the 
previous  page.  If  the  name  is  neither  recognized  nor  ambiguous 
in  that  context/  search  continues  in  the  next  context  on  the 
stack.  If  the  name  can  be  recognized  in  none  of  the  contexts 
on  the  appropriate  stack/  it  is  unrecognizable. 

When  a  stack  is  empty/  the  recognition  procedure  is  different. 
The  search  is  carried  on  in  a  special  context:  the  context  of 
£0PEN.  Its  top  node/  SOPEH/  is  a  built  in  system  ident. 
Subordinate  to  £0PEN  is  a  context  for  each  open  directory  node. 
Eacii  such  context  represents  all  the  idents  defined  in  the 
associated  data  description.  Thus,  if  there  were  two  open 
directory  nodes  having  data  descriptions: 

F  FILE  LIST  R  STRUCT  A  STR  Cl)  ft  STR  Cl) 

and: 

P  PORT  LIST  R  STRUCT  A  STR  (1)  B  STR  Cl) 
then  the  context  of  £0PEii  would  be  as  in  Figure  9.1-3. 
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Figure  9.1-3 


The  context  of  TjOPEN 
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When  a  directory  node  is  closed/  the  corresponding  context  is 
removed  from  the;  context  of  20PEN.  When  a  node  is  opened,  the 
associated  context  is  added  as  the  rightmost  context 
subordinate  to  £GPEN. 

9.2  Context  Stack  Maintenance 

The  context  stacks  are  always  empty  between  requests.  The 
FOR-operator  adds  entries  to  the  stacks.  FOR  A  adds  the 
context  of  A  to  the  input  context  stack.  FOR  A,  B  ...  adds 
the  context  of  A  to  the  output  stack  and  the  context  of  B  to 
the  input  stack. 

When  adding  to  an  empty  stack,  FOR  adds  two  contexts  instead  of 
one.  The  second  addition  to  the  stack  is  the  context  of  the 
looparg;  the  first  addition  is  the  context  of  the  outermost 
container  which  encloses  the  looparg. 

For  example,  given  a  context  of  %0PEN  as  in  Figure  9.1-3,  and 
empty  context  stacks,  the  fragment  'FOR  F.R  ...'  adds  two 
contexts:  (1)  the  context  of  F,  and  (2)  the  context  of  F.R. 

Contexts  are  removed  from  the  stacks  by  the  END  matching  the 
FOR  which  added  them. 
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10.  Miscellaneous  Topics 


10.1  The  LIST-request 

The  LIST-request  provides  a  means  for  the  user  to  inspect 
system  data  of  interest  to  him.  The  user  can  determine  the 

contents  of  the  directory,  the  source  or  parsed  form  of  any 

data  description  !n  the  system,  and  the  mode  and  connection 
status  of  any  open  file  or  port. 

The  LIST  operator  has  a  single  operand,  which  can  have  any  of 

several  forms.  The  action  of  the  operator  is  to  output  a  list 

of  values  on  the  Datalangauge  output  port. 

To  output  a  list  of  pathnames,  the  operand  used  Is  '2ALL1. 
When  '^ALL'  appears  alone,  all  pathnames  in  the  directory  are 
listed.  When  '.^ALL*  appears  after  the  last  Ident  in  a 
directory  pathname,  the  full  pathnames  of  all  nodes  subordinate 
to  the  named  node  are  listed. 

To  determine  the  status  of  the  open  files  and  ports,  the 
operand  '£0PEN'  is  used.  It  outputs  directory  pathname,  mode 
and  connection  status. 

To  output  one  or  more  source  descriptions,  the  operand 
1 . ^SOURCE 1  is  used.  '.^SOURCE'  is  preceded  with  one  of  (a) 
'SALL',  (b)  '  f,0PEN',  or  (c)  the  ident  of  an  open  outermost 
container.  The  output  is  either  (a)  all  descriptions,  (b)  all 
open  descriptions,  or  (c)  a  particular  open  description. 

To  output  a  parsed  description,  the  operand  1  ,?;DESC'  is  used 
( '^DESCRIPTION'  is  also  accepted).  This  operand  is  preceded 
either  with  (a)  'fjOPEN',  or  (b)  the  ident  of  an  open  outermost 
contai ner . 

Exampl es: 

Let  P  be  the  ident  of  an  open  PORT.  Let  A.B.C  bo  a 
directory  pathname. 

LIST  ',ALL 
LIST  A.B.C.5ALL 
LIST  fcUPEN 
LIST  5ALL.5SOURCE 
LIST  50PEM.%SUURCE 
LIST  P .  '.SOURCE 
LIST  50PEN.SDEGC 
LIST  P.SDESC 

Note  that  'LIST  A.B.C.  ^SOURCE'  is  riot  legal  --  '.^SOURCE' 
must  be  preceded  with  the  ident  of  an  open  container,  not  a 
pathname.  A  similar  restriction  applies  to  '.^DESC'. 

uQ 


•®S**323S? 


Specifications  for  Datal anguage,  Version  0/9  Page  25 


10.2  Constants  in  Uatal anguage 

A  constant  of  type  STRING  can  be  included  in  a  Datalanguage 
request  by  enclosing  it  in  single  quotes: 

'AUC' 

A  single  quote  is  included  in  a  constant  by  preceding  it  with  a 
double  quote: 

'FATHER"' S' 

Likewise,  a  double  quote  is  included  by  preceding  it  with  a 
double  quote: 

'JOHN  SAID  ""HELLO""' 

Such  constants  can  be  used  or  the  right  of  comparison  operators 
and  of  assignment  operators  wi  ich  reference  strings. 

Eventually,  Datalanguage  will  contain  facilities  for  the 
inclusion  of  constants  of  all  datatypes;  such  constants  are 
simply  a  special  case  of  the  Datalanguage  expression  and  will 
be  permitted  wherever  such  expressions  are  permitted. 

10.5  Character  Set 

Internally,  Version  0/9  of  the  Datacomputer  software  operates 
in  7-bit  ASCII  characters.  Its  output  to  the  ARPANET  is 
converted  to  8-bit  ASCII.  On  input  from  the  ARPANET,  it 
expects  S-blt  characters,  which  it  converts  to  7-bit 
characters . 

To  convert  from  7-  to  8-bit  characters,  a  'O'  bit  is  prefixed. 
To  convert  from  8-  to  7-bit  characters,  the  high-order  bit  is 
checked.  If  the  high-order  bit  is  a  'O',  the  bit  is  discarded 
and  the  character  is  accepted  as  a  7-bit  character.  If  the 
high-order  bit  is  a  '1',  then  the  character  is  discarded. 

(In  the  following  discussion,  as  elsewhere  in  this  memo,  all 
references  to  numerical  character  codes  are  in  decimal). 

The  remainder  of  this  section  discusses  treatment  of  codes  0 
through  127,  when  they  appear  in  Datalanguage  requests. 

In  general,  printing  characters  are  acceptable  in  requests, 
while  control  characters  are  not.  There  are  some  exceptions, 
which  are  detailed  below.  The  printing  characters  are  codes 
32-120.  The  control  characters  are  codes  0-31  and  127. 

Certain  control  characters  are  accepted: 

Tab('J)  is  accepted  freely  In  requests.  It  functions  as  a 
separator  (explained  below). 

E0L(31),  meaning  end-of-llne,  is  accepted  in  requests, 
functioning  both  as  a  separator  and  an  activator  ( a) .  EOL 
has  a  special  meaning  in  data,  and  should  not  be  introduced 
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into  STRING  constants (***) . 

Control -L( 12)  is  an  activator  and  a  high-level  request 
delimiter.  It  terminates  the  text  of  any  request  being 
processed  when  it  is  encountered  in  the  input  stream.  It  is 
useful  in  Uotacomputer-user  program  synchronization. 

Control -Z( 26)  means  end-of -scss I  on  when  encountered  in 
Datalanguage.  It  has  the  properties  of  control-L,  and  in 
addition,  causes  the  Dataconputer  to  execute  an 
end-of- sess ion  procedure,  which  results  in  closing  the 
Datalanguage  connections,  closing  any  open  files  or  ports, 
etc.  The  effect  is  equivalent  to  a  L0G0UT(wh i ch  does  not 
exist  yet). 

The  two-character  sequence  <carriago  return(13),  line 
feed(lU)>  is  equivalent  to  EOL  (and  is  translated  to  EOL  on 
input  from  the  network).  The  reverse  sequence,  as  well  os 
either  character  alone,  is  treated  simply  as  other  control 
characters  (ignored). 

Ail  other  soalxol  diarac.lar.s  ignored . 

The  printing  characters  are  further  divided  into  four  groups: 
special  characters,  upper  case  letters,  lower  case  letters,  and 
digits  (the  membership  of  these  groups  is  defined  in  section 
11). 

Corresponding  upper  and  lower  case  letters  are  equivalent  in 
requests,  except  within  quoted  strings. 

Certain  special  characters  have  a  lexical  function,  which  is 
either  Ur.eal;  or  separator .  A  break  character  terminates  the 
current  lexical  item  and  returns  itself  as  the  next  item.  A 
separator  character  terminates  the  current  item  but  does  not 
begin  a  new  item  (i.e.,  its  only  function  is  to  separate  items). 
Multiple  separators  are  equivalent  to  a  single  separator.  A 
separator  can  always  be  inserted  before  or  after  a  break 
character,  without  altering  the  meaning  of  the  request. 

The  separators  are  tab('J),  space(32),  and  erid-of-1  ine(31) . 

The  break  characters  are  left  paren thos  i  s ( 40 ) ,  right 
parenthesi s ( 4 1 ) ,  equals(Ol),  semi  col  on ( 39 ) ,  period(4C), 
conna(44),  quote(39),  and  slash(47). 


lAl  An  activator  character  causes  the  Dataromputer  to 
process  whatever  has  been  received  since  the  previous 
activator  or  the  beginning  of  the  request.  The  meaning 
of  a  request  is  independent  of  the  presence/absence  of 
activators.  However,  a  request  will  not  be  executed 
until  an  activator  beyond  the  end  of  the  request  is 
received.  , 
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While  Version  0/9  defines  (carriage  return,  linefeed)  in  terns 
of  EOL,  network  users  should  not  think  in  terns  of  sending  EOL's 
to  the  Uataconputer  over  the  network.  EOL  is  not  part  of  the 
network  ASCII  character  set,  and  has  no  definite  pernanent  place 
in  Oatacomputer  iropl cnentat ion  plans. 

10.4  Comments 

Comments  can  be  included  in  Datalanguage  requests.  A  comment  is 
begun  with  the  two-character  sequence  '/*'/  and  ended  with  the 
two-character  sequence  '*/*.  Since  slash  is  a  break  character, 
a  comment  does  cause  a  lexical  break;  its  overall  effect  is  that 
of  a  separator.  ,  n 


A 


iim: 


am 
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10.5  Reserved  Identifiers 

Certain  identifiers  are  reserved  In  Datal anguage ,  and  should  not 
be  used  to  name  containers  or  directory  nodes.  These  are: 

AND 

APPEND 

AT 

CLOSE 

CONNECT 

CREATE 

DELETE 

DISCONNECT 

END 

EQ 

FILE 

FOR 

GE 

GT 

LE 

LIST 

LT 

MODE 

NE 

NOT 

OPEN 

OR 

PORT 

READ 

STR 

STRUCT 

TO 

WITH 

WRITE 


More  reserved  identifiers  will  be  added  in  Version  0/10. 
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11.  Jatdl  on  ;jo.3G  Syntax  Expressed  in  DKF 


11.  i  .<equesti> 


11.1.01 

<request> 

:  :  = 

1 1 . 1 . 0 1 

<ro;iuest> 

;  ;  = 

<crreto>  ; 

11. 1.03 

<  request > 

: :  = 

Jf*E!i  <r>n)  ; 

11. 1.04 

< request > 

;  ;  = 

OPEN  <pn>  <iiOf'e>  ; 

11.1.03 

<roqucst> 

CLOSE  <  i  r'en  t>  ; 

x  1  •  1 .  J  0 

Crequcst  > 

CONNECT  <  i  dent)  TO  <odc!ress> 

11. 1. J7 

Oequost) 

DISCONNECT  Cider.t)  ; 

i  1 .  1 . 0  0 

< request > 

ICHE  <  i  cVnt)  <i  ede)  ; 

11.1. JJ 

<  request) 

:  :  = 

DELETE  < pn>  ; 

11.1. 1J 

<requests 

:  :  = 

LIST  < lister-)  ; 

11.1.11 

<  request) 

<sr -request)  ; 
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11.2  Data  Description  and  Creation 

11.2.01  <create>  CREATE  <pn> 

11.2.02  <create>  CREATE  <pn>  <ftn>  LIST  <drsc> 

11.2.03  <crcate>  ::=  CREATE  <pn>  <ftn>  LIST  <size>  <dcsc> 


11.2.04 

<desc> 

<ident>  <attributes> 

11.2.05 

<at tr i butes>  : :  = 

LIST  <size>  <desc> 

11.2.06 

<attr i butes>  : :  = 

STR'JCT  <descs>  END 

11.2.07 

<attr i butes>  :  :  = 

STR  <size> 

11.2.08 

<attributes> 

ST.R  <size>  ,  1*0 

11.2.00 

<Jescs> 

: : =  <desc> 

11.2.10 

<descs> 

: : *  <descs>  <desc> 

11. 2.11 

<ftn>  : 

:=  PORT 

11.2.12 

<ftn>  : 

:=  FILE 

11.2.13 

<ftn>  : 

:=  TEMP 

PORT 

11.2.14 

<ftn>  : 

:=  TEMPORARY  PORT 

11.2.15 

<s i ze> 

(  <integer  constant>  ) 
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I 

I 

l 

I 
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11.3  jota  3t;orn<»o  and  ivctrioval 

11.3.J1  <sr-rcqucst>  ::=  (assign) 
11.3.02  <sr-r oquest>  ::=  <loor»> 

11.3.03  <acsi~n>  ::=  <pn>  =  <r:"jcct> 


11.3.04 


<  1  oot>> 


F0:i  <loopar~>  <locobody> 


* 


1 

i 

l 

1 

i 

l 

l 

l 


11.3.05 

<  1  oopar  <j> 

:  :  =  <exp> 

11. 3 . 0  u 

<  1  oopar  ■£> 

: :  =  <  pn>  ,  <oxp> 

11.3.07 

< 1 oonuody> 

:  :  =  <sr~rr>qurst> 

11.3.03 

< 1 oopbody) 

::=  <  loepbodyl)  <sr-rcquest> 

i  1 .  3 . 0 1 

< 1 oopbody) 

::=  <  loopbodyl) 

11. 3. la 

< 1 oopbody 1> 

:  :  =  <3r-roq'jest>  ; 

11.3.  11 

<  1  oopbody 1> 

::=  <lcoobodyl)  < sr-request)  ; 
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11.4  Expressions 


11.4.01 

<oxp>  :  :  = 

<pn> 

11.4.02 

<exp>  :  :  = 

<pn>  WITH  <boolexp> 

11.4.03 

<bool exp> 

::=  <pn>  <conop>  Nstring  constant/ 

11.4.04 

<boo 1exp> 

: : =  (  <boo 1 exp>  ) 

11.4.05 

<boc 1 exp> 

::=  HOT  <booloxp> 

11.4.00 

< JOGlGXp) 

::=  <;oolcx,.>>  A*!0  <ooolcxp> 

11.4.07 

<  boo  1 o  x  p  > 

::=  <boclexp>  J".  <'.-ool cxp> 

1 1 . 4  .  j  o 

<cun,cp>  :  : 

»  E  1 

•i  1  •  4  •  j  J 

<coiicp>  :: 

=  i:e 

11.4. lj 

<Gouop>  : : 

=  m 

11.4.11 

<conop>  :  : 

=  LT 

11.4.12 

<coi  iOp>  : : 

-  CE 

11.4.13 

<co;':op>  :  : 

=  LE 
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11.5  i  seel  1  oneous 


11.5.01  <jJdrcss>  ::= 

<  4 JO tC> 

11.5.02  <uvidrcss>  ::  = 
11.5.03  < a  Id  r e  s  s >  :  :  = 


<quote>  <  T  E  i !  £  X  fils  Jcs  i  ^natcr) 

<socket>  AT  <!.cst> 

<sockc  t> 


Il.j.u4  <socket)  ::  =  <  Integer  constort)  // 1 NTCDPDPTE:'  '3 

jeci;:al 


i.1 . 5  .  J5  <kost>  <intC2cr  constant)  // 1 ''TE’TP:? ETEI  A3 

J  EC  I.IAL 

11.5.0C  Ciost>  *****  TCNEX  I.cst  necics  ***** 

11.5.07  <cbject>  <pn> 

11.5.03  <object>  ::=  <strinf2  constant) 

11.5.00  <;,iode>  ::=  dCAO 

11.5.10  <i;:OuC)  ::=  APPEND 

11.5.11  <i.,o<Je>  ::=  jpjTE 

h* 
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11.5.12 

<1  i  star.;) 

::=  5 ALL 

11.5.13 

< 1  i  stars) 

< pn)  .  feALL 

11.5.14 

<  1  i  star,;) 

::=  SOPEfi 

11.5.15 

< 1  i  starg) 

::=  IMl  .  ‘LGOURCt* 

11.5.1b 

< l 1 STARG) 

::=  <!DEHT>  .  ^JGLMCE 

11.5.17 

< 1 i starg) 

::=  iOPEf:  .  SOURCE 

11.5.1b 

< 1 i starg) 

::=  iOPEfl  .  JDE5C 

11.5. 1J 

< 1 i starg) 

:.*=  <  i  dent)  .  ;.)EGC 

11.5.20 

<pn>  :  :  = 

< i dent) 

11.5.21 

<  pn  >  :  :  = 

<  pn) . < i dent) 

11.5.22 

< i dent)  :  : 

=  < letter) 

CN 

• 

• 

H 

H 

< i dent)  :: 

=  <ident>  <  1  e tter) 

11.5.24 

<  i  dent)  : : 

=  <  i  dent)  <Jigit> 

11.5.25  <integcr  constant)  ::=  <dis:it> 

ll.j.26  <integer  constant)  ::=  <integor  constant)  <  c!  i  s  i  t  > 

11.5.27  <string  constant)  <quote>  <strins  conbody) 

<quote> 

11.5.23  <string  conbcd;)  ::=  <nor.quote> 

<string  conbody)  <strir<g 
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conbody)  <nonqucte> 
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11. L  Character  Cot 

11.6. 01  <soparator>  //SPACE(32) 

11.0.02  <separator>  //TAJ(O) 

11.0.03  <separator>  <ed> 


11.6.04 

<spec i al > 

<quote> 

11.6.05 

<spec i al > 

<supcrquote> 

ll.o. 06 

<spcci al > 

:  :  =  <spec i a  1 1) 

11.6.07 

< 1 etter> 

:  :  =  A 

11.6.03 

<lctter> 

:  :  =  J 

11.6.00 

< letter) 

•  z 

•  •  tm 

11.6.1J 

< letter) 

: :  =  a 

11.0.11 

<1  otter) 

:  :  =  b 

11.6.12 

<1 etter) 

: :  =  z 

11.6.13 

<di gi t> 

: :  =  0 

11. 6. 14 

<d  i  gi  t> 

:  :=  1 

•  •  =  'J 

«  •  J 


ll.o.l!)  <digit> 
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[  11.0. lb 

<nonquote> 

j  •  a 

< letter) 

j  11.5.17 

<nonquote) 

: :  = 

<di ci t> 

11.0.13 

<nonquotc> 

: :  = 

<superquote>  <quote> 

|  11. G. 13 

<nonquote> 

: :  = 

<superquote>  <superquote) 

11.G.20 

f 

<nonquote> 

: :  = 

<spec i al 1) 

1  11.0.21 

<nonquote> 

11  = 

<  separator) 

11.G.22 

<eol>  : : = 

//EOL  (31) 

J  11.0.23 

<eol> 

<carriase  return)  <line  food) 

|  ll.b.24 

<carriase  return) 

//CA.1.11  ACE  P.ETU1M  (13) 

|  n'°'25 

< 1 i ne  feed) 

•  • 

//LI  j E  FEED  (10) 

|  11.G.26 

<quote> 

1 

//SINGLE  3UOTEU4) 

|  H.o.27 

<superquote) 

•  • 

"  // DOL'D LE  mIUOTE(  34  ) 

^  11.G.22 

<spec i al 1) 

:  :  = 

1  //CXCLA!  IATI  Oi:  POIMTC33) 

|  11.0.23 

<  spec i a  1 1) 

: :  = 

»  //NU.MBC3  SI  011(35) 

11. o. 30 

<spec i a  1 1) 

:  :  = 

$  //DOLLAP  SI  GN (  30) 

1  11.0.31 

<speci al 1) 

: :  = 

S  //PERCENT  S 1 CH( 37 ) 

.  11.0.32 

<speci al 1) 

: :  = 

a  //a:ipeisand(3C) 

3 

■  11.0.33 

<spec i a  1 1) 

: :  = 

(  //LEFT  PAPENTIIE5  1  S(  40) 

|  11. b . 34 

<  spec i a  1 1) 

: :  - 

)  //ill  Gi IT  PA.PEMTMES  1  S(  41) 

11.0.35 

<spec i al 1) 

: :  = 

*  //A3TE.TI  SK(  42) 

I  ll.o.3b 

<SPECI ALl) 

: :  = 

+  //PLUS  S 1 GN( 43) 

1 

1 
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11.6.37 

<speciall>  : 

"  / 

11.6.33 

<specia11>  : 

= 

U.o.  30 

<speciall>  : 

”  • 

11.6.40 

Cspecial 1>  : 

»  / 

11.6.41 

<specia11>  : 

—  • 

• 

11.6.42 

especial 1>  : 

—  • 

11.6.43 

especiall)  : 

=  e 

11.6.44 

espec i a  1 1>  : 

=  S 

11.6.45 

especiall)  : 

=  > 

11. o.46 

especial 1>  : 

=  ? 

11.6.47 

espec i al 1>  : 

_  1 

-  tj 

11.0.43 

espec i al 1>  : 

=  [ 

11.0. 40 

espec i al 1> 

=  \ 

11.6. 50 

especial 1>  : 

=  ] 

11.0.51 

especiall>  : 

A 

11.6.52 

espec i a  1 1>  : 

=  — 

11.6.53 

especai 1 1>  : 
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